[アップデート] DynamoDB の継続的バックアップの保持期間が 1日から35日の間で設定可能になりました
こんにちは!クラウド事業本部コンサルティング部のたかくに(@takakuni_)です。
DynamoDB の継続的バックアップ(ポイントインタイムリカバリ)の保持期間が 1 日から 35 日の間で設定可能になりました。
アップデート内容
アップデート前までは、継続的バックアップの保持期間は一律 35 日でした。
最大 35 日前までの特定時点に復元できる機能は大変魅力的ですが、「バックアップは X 日とする」といったコンプライアンス要件や規制要件を満たせない(バックアップを取りすぎる)ケースが気になります。
今回のアップデートで上記の要件に満たせるよう、継続的バックアップの保持期間が設定できるようになりました。
やってみる
それでは、やってみましょう。
API Changes を見ると RecoveryPeriodInDays
が増えた模様です。
client.update_continuous_backups(
TableName='string',
PointInTimeRecoverySpecification={
'PointInTimeRecoveryEnabled': True|False,
'RecoveryPeriodInDays': 123
}
)
まずは新規構築した DynamoDB テーブルの PITR 画面を見てみます。
編集をクリックします。
普段のポイントインタイムリカバリの有効化オプション
に加えて、 バックアップリカバリ期間
が増えていました。
保持期間が 7 日に設定できていますね。
ドキュメントによると、既存のテーブルも修正できるようです。
You can edit the PITR setting on your table and change the recovery period. If you change the recovery period and increase it to a value higher than previously set, your EarliestRestorePoint will not change immediately. Since the recovery period is a rolling window, DynamoDB will continue to take automatic backups until the new increased period reached. If you change the recovery period and decrease it to a value lower than previously set, your EarliestRestorePoint will immediately decrease to match you recovery period, and any continuous backups that fall outside of the new set value will not be recoverable. .
ちょうどいいところに PITR を有効にしたテーブルがあったので変更してみます。
保持期間をデフォルトの 35 日から 7 日に変更してみます。
注意書きに最も早い復元ポイント
が短くなる旨が記載されていますね。
変更を保存をクリックすると、さらに念押しされました。更新をクリックします。
ドキュメントの通り、直ちに最も遅い復元日
が直ちに変更されていますね。
復元画面も 最も遅い復元日
に変更されています。
コスト
継続的バックアップ保持期間によって、コストメリットはあるのか?が気になったので調べてみました。結論、PITR は DynamoDB のテーブルサイズに基づいて課金されるため、コストメリットは薄いと思います。
DynamoDB の PITR に対して発生する料金は、PITR が有効になっている各 DynamoDB テーブル (テーブルデータおよびローカルセカンダリインデックス) のサイズに基づいて決まります。DynamoDB では、PITR が有効なテーブルのサイズが毎月継続的にモニタリングされ、バックアップ料金が決定されます。課金は、各テーブルの PITR が無効になるまで続きます。
アジアパシフィック(東京)
USD 0.228/GB-月
まとめ
以上、「継続的バックアップ(ポイントインタイムリカバリ)の保持期間が 1 日から 35 日の間で設定可能になりました。」でした。
特定のコンプライアンス要件に満たしながら、 PITR をしたいケースにはぴったりなアップデートですね。
このブログがどなたかの参考になれば幸いです。
クラウド事業本部コンサルティング部のたかくに(@takakuni_)でした!